Skip to main content

Develop in Single or Multiple Projects

Bizagi Projects​

This article explains what a project in Bizagi is and presents a list of considerations to help you decide when to automate in a single project or in multiple projects.

You may hear someone referring to a project as a project instance. They both mean the same thing:

Think of a Bizagi project instance as a file. Each file is independent from each other; it has access rights that are defined independently from other files, and teams can work collaboratively on them. A Bizagi project instance can contain as many processes as needed to accomplish your automation initiative.

Bizagi projects are automated in the development environment using Bizagi Studio. That is where you define your company’s process flows, the data structure, the business rules, and all the underlying components of a fully automated process.

Each project requires its own bundle of development-test-production environments, purchased separately. Thus, each project has AT LEAST three environments: the development environment, a testing environment, and the production environment.
You can opt to have more environments for your project if your business requires it, such as a Staging environment.

If you are thinking of having multiple production environments (and thus, develop on multiple project instances), you need to purchase a development and test environment INDEPENDENT for each project.

The following image shows Bizagi’s infrastructure, presenting how multiple projects are provisioned:

Bizagi Infrastructure

In a single project, multiple developers can work collaboratively, using Bizagi Studio from their workstations and running the development environment's Work Portal using a web browser. Any change made by a developer is reflected in the project's database, and all developers can see the changes reflected.

Multiple projects are used to deliver different implementations when you want to have independent cloud resources for each project, a different set of developers, or a different set of end users accessing each production environment.
Since an independent bundle of development-test-production environments is needed, when working with multiple projects, EACH project requires its own test and production environments.

Depending on your business scenarios, automating in a single project instance or in multiple project instances is equally valid.

When moving to PaaS, automatically consolidating multiple projects into one is not supported. Customers should buy independent dev-test-production environments per project, or involve Professional Services when buying only one project to analyze approach and recommendations.

Project Provisioning

Data and Metadata Sharing​

  • Single Project:
    All developers share the same project structure (data model), as well as global definitions such as Organization, Security definitions, Library rules, among others. All processes created share the metadata and data. A single project has separate environments (development, test, and production) with their own URL and database.

  • Multiple Projects:
    Each project has its own structure. No data or metadata is shared among them. Development teams are independent, and cloud resources are isolated from one team to another. Each project has separate environments (a development environment and their corresponding test and production), with different URLs and databases segregated by project and by environment.

User Management​

Developers in Studio Cloud Services​

Bizagi Studio is the tool used by developers to automate processes. The authentication for all projects relies on the identity provider configured in the Customer Portal.
You can configure multiple identity providers. This is useful when developing under a single project and having developers logging in with different domains.

  • Single Project:
    There is one development team. Access rights to work in the project in Studio are granted through the Customer Portal.

  • Multiple Projects:
    Access rights for each project are independent. If a user has access to one project, they must be granted access to work in another if required.

End Users in the Work Portal​

The Work Portal is a web application that lets each user perform their corresponding tasks and configurations. Before working in the application, each user must identify themselves to the system so that only the right people can perform such activities.

  • Multiple Projects:
    If you need to isolate and separate all access rights for end users to the processes in a project, consider creating multiple projects. Remember that each project has its own URL and authentication configuration.

Administrators in the Work Portal​

The Work Portal is managed by end users with specific roles that grant access to the different administration menus.

  • Single Project:
    Containing processes managed by people in different departments or organizations requires consideration for User management. Admin users in the Work Portal will be able to manage ALL end users in the project.

Deployments​

  • Single Project:
    All packages deployed to the test or production environments must always come from the same development environment. While deploying, a maintenance window is displayed for some seconds.

  • Multiple Projects:
    Deploying packages is independent for each project. The unavailability of the Work Portal only affects the project where the execution happened.

Project Management​

All projects and their environments (dev-test-prod) are managed through the Customer Portal. Each project has independent access rights defined. However, Company administrators can manage all projects.

VPN and Disaster Recovery​

  • Disaster Recovery Service (DRS):
    This is INDEPENDENT for every Production environment. Customers can purchase one, two, or three DRS for their Production environments.

  • VPN:
    A single VPN applies for the entire subscription, covering Studio Cloud Services, Automation Services, and all environments. Additional VPNs must be purchased when acquiring DRS.

Configuring Security in Single Projects​

Project’s Structure​

To achieve greater segregation levels, consider breaking down processes into different Bizagi Studio Applications.

  • Use Applications when having different teams working on a single project and their processes are independent.
  • Multiple Applications allow better organization and permission management for end users in the Work Portal.

Access Rights to Menus and Processes​

Set access rights to elements of the Work Portal. Restricted elements will only be visible to users with the correct access rights.

Case Security​

Define access rights for cases in the Work Portal to ensure that users without privileges cannot see any information on a case.